Ответственность

В РАЗРАБОТКЕЛАБОРАТОРИЯНЕ ОБЯЗАТЕЛЬНО

Ответственность в IT

1. Правовые и этические основания

Ответственность в сфере информационных технологий — это сложная, многоуровневая категория, включающая юридические, организационные, технические и этические аспекты. Она возникает в момент, когда субъект (физическое или юридическое лицо) приобретает возможность влиять на состояние информационных систем, данные, процессы и, следовательно, на права и интересы других участников цифровой среды.

В контексте IT ответственность не ограничивается исполнением должностных инструкций. Она распространяется на последствия технических решений, на качество реализованных функций, на устойчивость систем к внешним воздействиям, на конфиденциальность и целостность данных, на соблюдение требований законодательства и стандартов отрасли. При этом границы зоны ответственности могут быть динамическими: они смещаются в зависимости от полномочий, уровня доступа, принятых на себя обязательств и даже от степени осведомлённости о потенциальных рисках.

Понятие ответственности

С точки зрения философии, ответственность — это осознанная готовность лица нести последствия своих действий или бездействия, особенно в тех случаях, когда эти действия затрагивают интересы других. В IT это проявляется в готовности разработчика проверить входные данные перед записью в базу, в стремлении системного администратора регулярно обновлять уязвимые компоненты, в решении архитектора выбрать проверенную схему хранения персональных данных вместо экспериментальной, но менее защищённой.

С юридической точки зрения ответственность — установленная нормами права обязанность лица претерпеть неблагоприятные последствия за нарушение правовых предписаний. В российском праве она оформляется в виде санкций, применяемых уполномоченными органами, и реализуется через механизм правоприменения. Однако в IT многие нарушения изначально не фиксируются как правонарушения — они могут быть выявлены только в ходе внутреннего аудита, расследования инцидента или при анализе причин сбоя. Таким образом, юридическая ответственность — это лишь внешняя, формализованная часть более широкой системы ответственности, в которую входят и внутренние, неофициальные, но не менее важные уровни.

Классификация видов ответственности

В правовой системе Российской Федерации выделяются пять основных видов юридической ответственности. Каждый из них имеет собственные признаки, условия наступления и последствия. В сфере IT они проявляются с учётом специфики технологических процессов и объектов права — информации, программного обеспечения, телекоммуникационной инфраструктуры, персональных данных и критической информационной инфраструктуры.

1. Административная ответственность

Административная ответственность наступает за правонарушения, предусмотренные Кодексом Российской Федерации об административных правонарушениях (КоАП РФ), и выражается в применении мер административного воздействия (штрафы, предупреждения, административное приостановление деятельности и др.).

В IT-сфере наиболее часто встречаются составы, связанные с:

нарушением требований к защите персональных данных (ст. 13.11 КоАП РФ);
нарушением порядка хранения и обработки информации ограниченного доступа (ст. 13.12 КоАП РФ);
распространением запрещённой информации (ст. 13.41 КоАП РФ);
нарушением правил эксплуатации средств защиты информации (ст. 19.7.1 КоАП РФ);
неисполнением оператором связи обязанностей по предоставлению информации для обеспечения безопасности (ст. 19.7.12 КоАП РФ).

Особенность административной ответственности в IT — в её «оперативности»: проверки проводятся надзорными органами (Роскомнадзор, ФСТЭК, ФСБ), протоколы составляются в течение короткого срока, а штрафы могут быть наложены как на юридическое лицо, так и на должностное лицо (руководителя, ответственного специалиста). При этом для привлечения к ответственности не требуется наличие прямого умысла — достаточно констатации факта нарушения и установления виновного лица.

2. Дисциплинарная ответственность

Дисциплинарная ответственность возникает внутри трудовых отношений и регулируется Трудовым кодексом Российской Федерации (ТК РФ). Она применяется работодателем к работнику за нарушение трудовой дисциплины — неисполнение или ненадлежащее исполнение трудовых обязанностей.

Для IT-специалистов дисциплинарная ответственность может быть связана с:

несвоевременной ликвидацией инцидентов информационной безопасности;
нарушением внутренних регламентов по работе с конфиденциальной информацией;
несоблюдением требований к версионированию кода и документированию изменений;
игнорированием предписаний по проведению аудитов или тестированию на проникновение;
несанкционированным внесением изменений в эксплуатационные системы.

Меры дисциплинарного взыскания, согласно ст. 192 ТК РФ, ограничены тремя формами: замечание, выговор, увольнение. При этом работодатель обязан соблюсти процедуру: затребовать письменное объяснение, учесть тяжесть проступка, стаж работы, наличие ранее наложенных взысканий. Для квалифицированных IT-специалистов, особенно в условиях дефицита кадров, применение дисциплинарных взысканий часто сопровождается внутренним расследованием и анализом корневых причин нарушения — с целью предотвратить повторение.

3. Уголовная ответственность

Уголовная ответственность — наиболее строгая форма юридической ответственности, наступающая за деяния, признанные уголовно наказуемыми Уголовным кодексом Российской Федерации (УК РФ). Она предполагает наличие состава преступления: объекта, объективной стороны, субъекта и субъективной стороны (умысел или неосторожность).

В IT уголовная ответственность чаще всего возникает по следующим статьям:

ст. 272 УК РФ (оказание услуг, не отвечающих требованиям безопасности, повлекшее по неосторожности тяжкие последствия) — например, при разработке ПО для медицинских или транспортных систем;
ст. 273 УК РФ (создание, использование и распространение вредоносных компьютерных программ);
ст. 274 УК РФ (нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей);
ст. 137 и 138 УК РФ (нарушение неприкосновенности частной жизни, незаконный сбор и распространение сведений о частной жизни);
ст. 202 УК РФ (воспрепятствование законной профессиональной деятельности журналиста, в том числе путём DDoS-атак);
ст. 183 УК РФ (незаконное получение и разглашение сведений, составляющих коммерческую, налоговую или банковскую тайну).

Важно подчеркнуть: привлечение к уголовной ответственности возможно как за умышленные действия (например, внедрение бэкдора с целью кражи данных), так и за неосторожные (например, непринятие мер к защите системы, знание о критической уязвимости, но неустранение её в течение длительного времени). При этом субъектом преступления может быть как индивидуальный разработчик, так и должностное лицо — руководитель службы ИБ, технический директор, ответственный за соответствие требованиям 152-ФЗ.

4. Гражданско-правовая ответственность

Гражданско-правовая ответственность направлена на восстановление нарушенного права, преимущественно через возмещение имущественного или морального вреда. Она регулируется Гражданским кодексом Российской Федерации (ГК РФ) и реализуется в порядке досудебного урегулирования или через судебное разбирательство.

В IT наиболее типичные основания гражданской ответственности:

нарушение условий договора на разработку программного обеспечения (например, срыв сроков, несоответствие спецификации, отсутствие поддержки);
причинение вреда вследствие сбоя системы (например, простой на производственной линии из-за ошибки в интеграционном модуле);
утечка персональных данных, повлёкшая моральный вред субъекту данных;
некорректное внедрение или сопровождение ERP/CRM-системы, приведшее к финансовым потерям заказчика.

Особенности гражданской ответственности в IT:

необходимость доказательства причинно-следственной связи между действием (бездействием) и наступившими последствиями;
возможность применения косвенного ущерба (упущенная выгода), если он был предсказуем на момент заключения договора;
частое включение в договоры положений об ограничении ответственности (например, исключение ответственности за косвенные убытки), что, однако, не освобождает от ответственности за вред, причинённый жизни или здоровью, или за умышленное нарушение.

5. Моральная (этическая) ответственность

Моральная ответственность не имеет формального механизма принуждения, но играет ключевую роль в профессиональной среде. Она основана на признании норм, закреплённых в кодексах профессиональной этики (например, ACM Code of Ethics and Professional Conduct, IEEE Code of Ethics, этических стандартах OWASP, а также внутренних корпоративных кодексах).

Этическая ответственность в IT включает:

отказ от разработки систем, способных причинить вред (военные ИИ, инструменты массового наблюдения без юридических оснований);
прозрачность в отношении ограничений и рисков используемых технологий;
уважение к пользователям: обеспечение доступности, информированного согласия, возможности отказа от сбора данных;
признание авторства, недопущение плагиата в коде и документации;
готовность сообщать о выявленных уязвимостях в порядке, не нарушающем интересы пользователей (в том числе через responsible disclosure);
участие в улучшении качества кода и архитектуры, даже если это не входит в прямую зону ответственности.

В отличие от юридических санкций, моральная ответственность влияет на репутацию, возможности карьерного роста, доверие со стороны коллег и заказчиков. В сообществе IT, где важную роль играют open-source-вклады, публичные выступления, экспертные оценки, этические нарушения могут иметь долгосрочные последствия, сравнимые с юридическими.

2. Ответственность по ролям

В современных ИТ-проектах ответственность распределена между множеством участников, каждый из которых вносит вклад на своём уровне абстракции — от написания строки кода до принятия стратегического решения о выборе технологического стека. Однако формальное разделение труда не означает автоматического разделения ответственности. Наоборот, в случае инцидента или нарушения часто выявляется, что ключевые точки ответственности сконцентрированы в узких местах — так называемых single points of failure в организационной структуре.

Разработчик программного обеспечения (Software Developer)

Разработчик несёт ответственность за корректность, безопасность и сопровождаемость реализуемой функциональности. Эта ответственность начинается задолго до компиляции кода и продолжается после его развёртывания.

Корректность реализации означает соответствие кода требованиям технического задания и спецификации интерфейсов. Даже если требование сформулировано нечётко, разработчик обязан выявить неоднозначности, запросить уточнения и зафиксировать принятое решение. Пренебрежение этим может привести к функциональным ошибкам, которые впоследствии будут расценены как нарушение условий договора (гражданско-правовая ответственность) или как грубая неосторожность (в случае прямого вреда).
Безопасность кода — базовое качество. Разработчик обязан применять принципы безопасной разработки: валидацию и санитизацию входных данных, использование параметризованных запросов, отказ от динамического выполнения кода по непроверенным входам, корректную обработку ошибок (без утечки стек-трейсов в клиентскую часть), управление зависимостями (обновление уязвимых библиотек). Невыполнение этих требований может повлечь административную ответственность (например, по ст. 13.11 КоАП РФ при утечке персональных данных через SQL-инъекцию) или уголовную — если будет установлено, что уязвимость была известна, но игнорировалась.
Сопровождаемость включает читаемость кода, наличие комментариев там, где это необходимо (не вместо, а в дополнение к самодокументируемому коду), соблюдение соглашений о стиле, покрытие тестами критически важных участков. Отсутствие тестов может не быть нарушением закона, но в случае сбоя, вызванного регрессией, это станет основанием для дисциплинарного взыскания или претензий по договору подряда.
Совместная ответственность. Например, при внедрении аутентификации через OAuth 2.0 разработчик несёт ответственность за корректную реализацию flow'ов и валидацию токенов, но не за выбор провайдера или настройку сервера авторизации — это зона ответственности системного администратора или DevOps-инженера. Тем не менее, если разработчик осознанно игнорирует рекомендации по использованию PKCE в public clients, а в результате происходит перехват кода авторизации, он может быть признан виновным в создании условий для компрометации.

Тестировщик (QA Engineer)

Тестировщик отвечает за достоверную оценку готовности продукта к эксплуатации. Его ответственность — информационная: предоставить заинтересованным сторонам объективную картину рисков.

Полнота тестового покрытия определяется на основе анализа требований, архитектуры и истории инцидентов. Если в системе ранее происходили отказы при высокой нагрузке, а нагрузочное тестирование не включено в регрессионный цикл, это может быть расценено как недобросовестное исполнение обязанностей.
Документирование дефектов должно быть точным, воспроизводимым и содержать контекст (окружение, конфигурация, цепочка действий). Неполные отчёты затрудняют анализ корневых причин и могут косвенно способствовать повторному возникновению инцидента — в этом случае ответственность может быть распределена между тестировщиком и командой поддержки.
Участие в оценке критичности. Тестировщик не принимает решение о выпуске, но обязан чётко обозначить, какие дефекты блокируют эксплуатацию с точки зрения безопасности, стабильности или соответствия законодательству (например, отсутствие поддержки согласия на обработку персональных данных в соответствии с 152-ФЗ). Если такое предупреждение было проигнорировано руководством, тестировщик сохраняет доказательства своей позиции (например, запись в задаче или протокол совещания), что снимает с него долю ответственности в случае последующего нарушения.

Системный администратор / Инженер инфраструктуры

Ответственность системного администратора лежит в области непрерывности, целостности и конфиденциальности инфраструктурных компонентов.

Обновление и патчинг. Отсрочка обновления критически уязвимого компонента (например, OpenSSL после публикации CVE) без документального обоснования (например, отсутствия совместимой версии в стабильном релизе ОС) создаёт объективные основания для привлечения к административной ответственности по ст. 19.7.1 КоАП РФ (нарушение требований по защите информации).
Резервное копирование и восстановление. Наличие бэкапов — необходимое, но недостаточное условие. Требуется проверка восстанавливаемости. Инцидент, при котором данные утеряны из-за их повреждения или несовместимости формата, может быть признан результатом халатности.
Контроль доступа. Принцип минимальных привилегий должен реализовываться функционально: например, учётная запись для CI/CD должна иметь доступ только к тем репозиториям и средам, которые действительно требуются для сборки и развёртывания. Выдача избыточных прав без обоснования — нарушение требований ФСТЭК и возможное основание для дисциплинарного взыскания.
Аудит и мониторинг. Администратор обязан обеспечить сбор и хранение журналов событий в объёме, достаточном для расследования инцидентов (например, не менее 6 месяцев по требованиям 187-ФЗ для КИИ). Отключение логирования «для повышения производительности» без согласования и оценки рисков — прямое нарушение.

DevOps-инженер

DevOps-инженер сочетает в себе ответственность за инфраструктуру и за процессы доставки. Его зона ответственности — автоматизация без снижения контроля.

Конфигурация как код (IaC). Использование Terraform, Ansible, Kubernetes-манифестов и т.п. не освобождает от проверки содержимого. Ошибки в IaC (например, открытие порта 22 на публичный IP без ограничения по IP-диапазону) эквивалентны ошибкам в программном коде и влекут те же последствия — от административного штрафа до уголовного преследования при компрометации.
CI/CD-конвейеры. Инженер отвечает за корректность этапов: сборка, тестирование, проверка безопасности (SAST/DAST), подписывание артефактов, деплой. Если в pipeline отсутствует проверка на наличие уязвимостей в зависимостях (например, через OWASP Dependency-Check), а в результате развёрнута версия с известной RCE-уязвимостью, это может быть квалифицировано как неисполнение обязанностей по обеспечению безопасности.
Хранение секретов. Использование plaintext-паролей в репозиториях, даже в приватных, запрещено требованиями большинства стандартов (PCI DSS, ГОСТ Р 57580.2–2017). Ответственность за миграцию на vault-системы (HashiCorp Vault, AWS Secrets Manager) и интеграцию с CI/CD лежит на DevOps-инженере. Утечка данных из-за хранения ключей в Git — прямой путь к административной ответственности.

Аналитик (Business / Systems Analyst)

Аналитик — «переводчик» между предметной областью и технической реализацией. Его ответственность — точность и полнота передачи требований, включая нефункциональные и регуляторные.

Фиксация требований к безопасности и соответствию. Если в банковском ПО не указано требование «все операции с деньгами должны логироваться с привязкой к пользователю и устройству», а впоследствии выясняется невозможность расследовать мошенническую транзакцию, аналитик может быть привлечён к ответственности за неполную проработку требований.
Учёт ограничений законодательства. Например, при работе с персональными данными аналитик обязан предусмотреть сценарии: сбор согласия, отзыв, право на забвение, ограничение автоматизированного принятия решений. Отсутствие таких требований в спецификации — нарушение принципа «privacy by design», закреплённого в 152-ФЗ, и основание для привлечения компании (и, возможно, аналитика как должностного лица) к административной ответственности.
Валидация обратной связи. После внедрения аналитик участвует в оценке, была ли решена бизнес-проблема. Если система введена в эксплуатацию, но не покрывает заявленные кейсы, а это было очевидно на этапе анализа, ответственность может быть разделена между аналитиком, руководителем проекта и заказчиком — в зависимости от того, кто принял решение о запуске.

Архитектор программного обеспечения

Архитектор несёт стратегическую ответственность за долгосрочную устойчивость системы. Его решения влияют на десятки других специалистов и определяют границы возможного в течение нескольких лет.

Выбор архитектурных решений. Решение использовать монолит вместо микросервисов, реляционную СУБД вместо документ-ориентированной, on-premise-размещение вместо облачного — технически нейтрально, но несёт юридические и экономические последствия. Например, выбор облачного провайдера, не сертифицированного ФСТЭК для хранения персональных данных категории «особая важность», делает невозможным легальное использование системы в определённых сферах (здравоохранение, госсектор), что может повлечь расторжение договора и регрессные требования.
Соблюдение стандартов. Архитектор обязан учитывать ГОСТ Р ИСО/МЭК 25010 (качество ПО), ГОСТ Р 57580 (безопасность), а также отраслевые стандарты (например, PCI DSS для платёжных систем). Несоответствие базовой архитектуры требованиям стандарта, даже если детали реализованы корректно, делает всю систему уязвимой с точки зрения аудита.
Документирование архитектурных решений (ADR). Отсутствие зафиксированных причин выбора — риск при расследовании инцидента. Если катастрофический сбой произошёл из-за отказа от репликации базы данных «для упрощения», а это решение не задокументировано и не согласовано, архитектор может быть признан виновным в халатности.

Руководитель проекта / Технический менеджер

Руководитель проекта отвечает за согласованность целей, ресурсов и ограничений. Его ответственность — управленческая, но она напрямую влияет на возникновение технических рисков.

Оценка и распределение задач. Назначение junior-разработчику задачи по реализации криптографической подписи без менторства и ревью — создание условий для критической ошибки. Если в результате подделываются документы, ответственность может быть возложена на руководителя как на лицо, допустившее необоснованное делегирование.
Управление рисками. Регулярная идентификация, оценка и планирование мер по снижению рисков — обязательная часть управления. Пренебрежение этим (например, игнорирование риска «отказ стороннего API» при построении интеграции) делает руководителя соучастником последствий.
Соблюдение сроков и качества. Давление на команду с требованием «выпустить любой ценой» может быть использовано в суде как доказательство умысла или грубой неосторожности, если это приведёт к вреду. В то же время грамотный менеджер фиксирует trade-offs: «Релиз в срок возможен при условии отсрочки аудита безопасности на 2 недели», — и получает письменное согласование.

3. Коллективная ответственность, международные аспекты и факторы смягчения

1. Совместная, солидарная и субсидиарная ответственность в командной работе

В ИТ-проектах редко бывает так, что один человек отвечает за весь жизненный цикл решения «от идеи до эксплуатации». Более типична ситуация, когда несколько специалистов последовательно или параллельно вносят вклад, а ответственность распределяется нелинейно. Юридически это выражается в трёх формах:

Совместная ответственность означает, что несколько лиц совершили правонарушение сообща, и каждый несёт ответственность в объёме своей вины. Например, разработчик внедрил insecure direct object reference (IDOR), тестировщик не проверил сценарий подмены идентификатора, администратор не ограничил доступ к API извне — все трое могут быть привлечены к административной ответственности, но размер вины будет оцениваться пропорционально их вкладу.
Солидарная ответственность применяется реже и означает, что потерпевший вправе требовать возмещения вреда полностью от любого из ответчиков, после чего тот вправе регрессно требовать компенсацию от остальных. Такой режим может быть установлен договором: например, при субподряде разработки компания-генеральный подрядчик и субподрядчик могут договориться о солидарной ответственности перед заказчиком за срыв сроков или некачественную поставку. Это усиливает мотивацию к контролю за исполнителями, но увеличивает риски для всех участников.
Субсидиарная ответственность наступает, когда основной ответчик не может полностью исполнить обязательство, и дополнительный ответчик отвечает в части недостающего. В ИТ это актуально при использовании сторонних компонентов: если библиотека с открытым исходным кодом содержит уязвимость, а разработчик не обновил её, несмотря на наличие патча, то формально вина лежит на авторе библиотеки, но в реальности ответственность несёт тот, кто принял решение использовать устаревшую версию в production — поскольку он обладал возможностью и обязанностью контролировать зависимости.

В российской судебной практике при рассмотрении дел, связанных с ИТ-нарушениями, суды всё чаще обращают внимание на фактическую возможность влиять на результат. Человек, не являющийся руководителем, но обладающий правом commit в основную ветку и игнорирующий замечания коллег о критической уязвимости, может быть признан виновным наравне с техническим директором.

2. Роль процессов контроля в распределении ответственности

Существуют организационно-технические практики, которые явно фиксируют зоны ответственности и снижают неопределённость:

Code review — механизм передачи ответственности. Ревьюер, одобривший merge request, тем самым подтверждает, что код соответствует требованиям безопасности, архитектуры и качества. Если впоследствии в этом коде будет обнаружена уязвимость, которую можно было выявить при внимательном ревью, ответственность частично переносится на ревьюера.
Архитектурные советы (Architecture Review Board) — формализованный процесс согласования ключевых решений. Протокол заседания с перечнем одобренных и отклонённых вариантов служит доказательством того, что решение принималось коллегиально, и снимает индивидуальную ответственность с архитектора.
RACI-матрицы (Responsible, Accountable, Consulted, Informed) — инструмент распределения ролей по задачам. Например, в задаче «настроить шифрование трафика между сервисами»:
— Responsible: DevOps-инженер (выполняет),
— Accountable: архитектор (несёт окончательную ответственность за корректность решения),
— Consulted: специалист по ИБ (даёт рекомендации),
— Informed: руководитель проекта (уведомляется о завершении).
Чёткая RACI снижает риск «никто не отвечает».
Внутренние регламенты и инструкции — документы, утверждённые приказом, имеют повышенную доказательную силу. Если в регламенте прописано: «Все изменения в production вносятся только после прохождения тестирования и подписания отчёта QA», а инцидент произошёл из-за обхода этого правила, ответственность ложится на нарушителя, а не на всю команду.

3. Ответственность в open source

Участие в open-source-проектах создаёт особую модель ответственности, поскольку отношения строятся вне трудового и договорного права.

Авторство и лицензирование. Автор сохраняет авторские права, но передаёт права на использование по лицензии (MIT, GPL, Apache 2.0 и др.). Лицензия определяет пределы ответственности: почти все open-source-лицензии содержат оговорку «as is, without warranties», то есть автор не несёт ответственности за ущерб, причинённый использованием ПО. Однако это не освобождает от уголовной ответственности, если ПО намеренно содержит вредоносный код.
Security disclosure. Этическая ответственность участника — сообщить об уязвимости мейнтейнеру до публичного раскрытия (responsible disclosure). Публикация эксплойта без предупреждения может быть расценена как хулиганство (ст. 213 УК РФ) или как содействие несанкционированному доступу (ст. 272.1 УК РФ), особенно если ПО используется в критической инфраструктуре.
Поддержка форков. Если организация форкает open-source-проект и использует его во внутренних системах, она берёт на себя полную ответственность за его безопасность и соответствие требованиям — даже если оригинальный проект не поддерживается. Прекращение обновлений после форка — самостоятельное решение, влекущее риски.

4. Фриланс и аутстаффинг

При найме внешних исполнителей границы ответственности часто размываются. Однако законодательство исходит из принципа контроля.

Фрилансер по ГПД (гражданско-правовому договору) несёт ответственность за результат. Если в договоре прописано: «Исполнитель гарантирует соответствие ПО требованиям ФЗ-152», а после сдачи выявляется отсутствие шифрования персональных данных — заказчик вправе потребовать устранения дефектов за счёт исполнителя или взыскать убытки. Однако административная ответственность (штраф Роскомнадзора) налагается на оператора, то есть на заказчика. Таким образом, заказчик может быть оштрафован, а затем регрессно взыскать сумму с фрилансера — если докажет его вину.
Аутстаффинг (персонал «в аренду»). Формально трудовые отношения — с аутстаффинговой компанией, а операционное управление — у заказчика. В случае инцидента (например, утечки данных из-за действий аутстафф-администратора) административная ответственность ложится на оператора персональных данных (заказчика), а дисциплинарная — на аутстаффинговую компанию. Чтобы распределить риски, в договоре между компаниями прописываются обязательства по обучению, аттестации и страхованию ответственности исполнителя.
Ключевой момент — документальное подтверждение передачи требований. Если заказчик устно сказал «сделайте как обычно», а не предоставил техническое задание с требованиями к безопасности, суд может снизить его долю вины, но не снять полностью — поскольку оператор обязан обеспечить соответствие независимо от действий подрядчика.

5. Экстерриториальное применение норм

Современные ИТ-системы редко ограничены одной юрисдикцией. Это создаёт риски множественной ответственности.

GDPR (Общий регламент по защите данных, ЕС) применяется ко всем организациям, обрабатывающим персональные данные граждан ЕС, независимо от места их регистрации. За нарушение предусмотрены штрафы до 4 % глобального годового оборота или 20 млн евро. Российская компания, принимающая заказы от европейских клиентов через сайт, подпадает под GDPR. Ответственность наступает даже при отсутствии представительства в ЕС — через назначение представителя (Art. 27) или напрямую через судебные запросы.
CCPA/CPRA (Калифорния) и VCDPA (Вирджиния) — аналогичные режимы в США, действующие на уровне штатов. Они предусматривают право на удаление данных, ограничение продажи информации и штрафы за утечки.
Конфликт норм. Например, GDPR требует хранения данных только при наличии законного основания, а российский ФЗ-152 требует хранения согласий в течение всего срока обработки и трёх лет после. Компания обязана соблюдать оба требования, что достигается за счёт тонкой настройки политик хранения и сегментации данных по географическому признаку.
Судебная практика. Европейский суд по правам человека и суды США всё чаще выносят решения по искам граждан против иностранных IT-компаний, основываясь на принципе целевого влияния (targeting). Если сайт локализован на язык страны, принимает платежи в местной валюте и рекламируется через местные каналы — это достаточное основание для применения местного законодательства.

6. Факторы, смягчающие и отягчающие ответственность

Законодательство (в частности, ст. 4.2 и 4.3 КоАП РФ, ст. 61 УК РФ) предусматривает перечень обстоятельств, влияющих на меру ответственности.

Смягчающие факторы:

добровольное сообщение о нарушении до начала проверки (например, уведомление Роскомнадзора об утечке в течение 24 часов);
принятие мер по устранению последствий (восстановление данных, уведомление субъектов, усиление защиты);
наличие сертифицированной системы менеджмента ИБ (например, по ГОСТ Р ИСО/МЭК 27001);
отсутствие умысла, первое нарушение, положительная характеристика;
активное содействие расследованию.

Отягчающие факторы:

сокрытие инцидента (например, отключение логирования после атаки);
повторное нарушение в течение года;
причинение вреда группе лиц (массовая утечка);
извлечение выгоды из нарушения (продажа данных);
нарушение в условиях чрезвычайной ситуации или угрозы безопасности.

Судебная практика показывает: компании, внедрившие регулярные аудиты, обучение персонала, incident response plan и застраховавшие киберриски, получают более мягкие санкции — даже при наличии формального нарушения.

7. Практические рекомендации по фиксации и минимизации ответственности

Документируйте всё, что влияет на безопасность и соответствие — для защиты. Протоколы совещаний, технические решения, согласования — храните не менее 5 лет.
Используйте шаблоны ADR (Architecture Decision Records) для фиксации архитектурных выборов с указанием альтернатив, критериев и рисков.
Внедрите внутренний регламент по управлению инцидентами ИБ, включающий:
— порядок выявления и классификации,
— сроки уведомления руководства и регуляторов,
— сценарии взаимодействия с пресс-службой и клиентами.
Проводите регулярные тренинги по правовым аспектам — для технических специалистов. Понимание, почему нельзя хранить пароли в открытом виде, снижает число нарушений.
Страхуйте профессиональную ответственность (cyber liability insurance). Полис покрывает штрафы, судебные издержки, расходы на уведомление субъектов данных — это не отменяет ответственность, но снижает финансовые последствия.